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emphasis on the particular advantages and disadvantages of 
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The integration of these two programming paradigms ia 
explored based on the notion that declarative sorts of 
knowledge (facts and logical relationships) should be 
expressed in a declarative way, and that procedural sorts of 
knowledge (manipulation, control” and utilization of 
knowledge) should be expressed in a procedural way. Toward 
this end, the conceptual framework for an integrated 
language is established, and the basic features of the 
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I. INTRODUCTION 


A. PROGRAMMING LANGUAGE DESIGN 

Programming language design represents both an effort to 
provide the necessary interface with the hardware of the 
computer and an effort to better capture the ideas of the 
programmer. As higher order programming languages evolve, a 
key factor in each language designed is the level of ab- 
straction afforded the programmer. Current conventional 
languages have removed the programmer from the hardware 
level of the machine. For instance, instead of being  con- 
cerned with which registers to use, the programmer can be 
more concerned with solving the problem at hand. For 
certain classes of problems, this higher level of  abatrac- 
tion increases the semantic power of the language and better 
captures the problem solving concepts of the programmer. 
The evolution of programming language design has resulted in 
solutions to a broader class of problems’ and even new 
approaches toward the solution of presently unsolved 


problems. 


B. PROBLEM COMPLEXITY 
The features of the language are the tools with which 
the programmer tackles a host of complex problems. As the 


problem complexity increases, the manner in which. one works 


toward a solution can be affected by the Pool or tools 
available. Consider the analogy of an automobile mechanic 
working on an automobile engine; a aimple tune-up, 
adjustment, or small part replacement can be performed with 
Simple handtoolsa and devices. However, if the problem is 
more complex, say involving the cylinders, camshaft, or 
drive train, then the mechanic cannot solve such problens 
with simple tools. The solution now requires more advanced 
tools like hydraulic lifts, pneumatic tools, and precision 
instruments. In fact, without more advanced Pooley, the job, 
if still possible, is solved through improvisation with the 
simpler tools and results in a less efficient and imprecise 


solution. 


C. SAPIR-WHORF HYPOTHESIS 

Similarly, the features of the programming language can 
effect the manner in which the programmer approaches the 
solution to a particular problem. This can be considered an 
application of the controversial Sapir-Whorf hypothesis 
which originated in linguistic theory (Ref. 1]. Assuming 
this hypothesis, the D OE RAT attempting to solve complex 
problens with a limited programming language cannot realize 
his full problem solving potential and must improvise with 
the available language features to work toward an acceptable 


solution. 


D. NON-CONVENTIONAL PROGRAMMING LANGUAGES 

Conventional programming languages do not offer the 
programmer a very high level of abstraction, have a 
restrictive “word-at-a-time” (Ref. 5: p. 404) programming 
atyle, and result in what Backus refers to as an 
"intellectual bottleneck” (Ref. 3]. The sequential nature 
of these imperative languages, through use of assignment 
atatements to alter memory, results in avon Neumann “mind 
set”, and places limitations upon the level of abstraction 
available to the programmer. Efforts to provide more 
semantic power to these languages has resulted in the 
development of the Ada (Ref. 6] programming language. This 
very large and very complex language provides increased 
semantic power at the cost of simplicity, clarity of 
understanding, and programmer mastery of his tool (Ref. 6]. 

Non-conventional programming languages, on the other 
hand, offer a break from the von Neumann mind set and help 
the programmer approach and solve problema from new 
perspectives. Such non-conventional programming languages 
are illustrated by PROLOG (Ref. 2,7], Backus’ FP language 
(Ref. 31, and SMALLTALK (Ref. 4]. Each of these languages 
represents an implementation of a particular programming 
language paradigm, namely, logic programming, functional 
programming ‘applicative programming with emphasis on 
functions as arguments), and object-oriented programming, 


respectively. Issues such as semantics, computational 


10 


power, parallelism, side effects, flexibility, simulation, 
and knowledge representation exemplify some of the basis for 
development of language design in each of these programming 


paradigms. 


E. RESEARCH FOCUS 

With these issues in mind, two programming paradigms, 
logic programming and functional programming, are discussed 
in detail. The emphasis of the discussion will be in terma 
of the particular advantages or disadvantages of each 
programming paradigm, often exemplified by the PROLOG or 
“pure” LISP implementation. The focus of this study will be 
toward the development of a theoretical foundation for the 
design of an integrated programming language which, of 
course, maximizes the advantages of both paradigms and 
minimizes their disadvantages. Such an integrated language 
Should broaden the scope of the programmer’s problem solving 
capability by providing a tool that is both semantically and 
computationally powerful, and offers improved control 


characteristics. 
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II. LOGIC PROGRAMMING 


A. BACKGROUND 

The foundation for the development of a programming 
language based upon the rigors of predicate logic seems to 
have grown out of early attempts to automate theorem proving 
(Ref. 5, 7, 11) and has subsequently been bolstered by the 
demands of the artificial intelligence (AI) community in an 
effort to live up to their rather ambitious name. Hewitt’s 
PLANNER (Ref. 11), a language designed for theorem proving 
and robot model manipulation, utilized such concepts as 
backtracking and a database of aaaertiona [Ref. 71, which 
would later be embraced by the designera of PROLOG. The 
theoretical foundation for programming in logic, however, ia 
probably best described in Kowalski'a work [Ref. 8, 9, 10]. 
In particular, his paper in the Communications of the ACM 
(Ref. 8], though concerned with predicate logic aa a tool 
for algorithm analysis, introduces the separation of the 
logic and control components of an algorithm and strongly 
suggests the usefulness of this concept in programming 
languages. Additionally, Kowalski definea the semantics of 
predicate logic programa (Ref. 91], in a collaboration with 


van Emden, regarding proof theory and model theory. 
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A logic S cras consists of the explicit use of Horn 
clauses in the process of goal satisfaction. Both Horn 
clauses and the process of goal satisfaction are described 
below. Additionally, the advantages and disadvantages 
afforded the programmer by using logic programming are 


detailed. 


B. HORN CLAUSE 
A Horn clause is a subset of the full predicate logic 
system that is. quantifier-free and contains at most one 


positive literal. It is the preferred logical formula in 


the expression of logic programs. Horn clauses can be 
represented by both the logical form, where  "-" means 
negation, and the standard convention, <head> <-- <body>, 
called a definite clause. The following four 


classifications of clauses are illustrated by both: 
1» Assertion (only one positive literal) 
B or B <-- 
2) Declaration (one positive literal and one or nore 
negative literala) 

B V “A, Mea Y "Án or B <-- Aj» +» A, 
3) Denials (no positive literals) 

TA, V-..V "Án or ccm Ar» 8, 
4) Contradiction (the empty clause) 


0 or <-- 
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C. GOAL SATISFACTION 

A logic program consista of a number of these Horn 
clausea, aa axioma, upon which the attempted satisfaction of 
a particular goal ia based (Ref. 12]. An important point 
here ia that these axioma are user defined and basically 
provide the ayatea interpreter with the facta required to 
determine whether a given goal is satisfiable. 

1. Resolution and Unification 

A logic programming interpreter attempts to solve a 
Sata, goal atatement by reaolving any subgoals within 
the statement with the heada of definite clauses of the 
logic program. Since the resolution process is one of proof 
by refutation, a goal is aatisfiable if the empty clause 
(contradiction) can be derived. During the derivation 
certain bindings for variables may be made which become the 
solution for the given goal atatement (Ref. 121]. 

There are several algorithms (Ref. 13, 14] for 
performing such unifications, the foundation of which is 
described by Kowalski (Ref. 9] and detailed by Hill (Ref. 
15], where he names the process LUSH (Linear resolution with 
Unrestricted Selection for Horn clauses). 

The LUSH rule of inference takes a given goal 
atatement Ayres AL and attempta to resolve a subgoal A; 
with a definite clause within the logic program that 
contains an identical form of A, as the head of the clause. 


i 
Recall that the actual form of the goal statement is 


l4 


"A. Viaja V E and that the subgoal being resolved ia “Aas 
Since the head of the clause is the positive literal, the 
unification of the subgoal and the definite clause resolves 


the literal A and replaces it with the body of the clause 


"L 
(Ref. 10, 161. This derivation is possible, of course, only 
if some general substitution function, mapping variables to 
ternas, makes the subgoal and the head of the definite clause 
identical (Ref. 10]. 
2.  Non-determinism 

Predicate logic ia non-deterministic in that the 
unification process follows a pattern matching scheme for 
resolution of subgoala and more than one definite clause may 
have a head that will match (Ref. 10, PI Therefore, a 
resolution procedure like LUSH requires a selection 
component and a search component [Ref. 161, where the 
selection component is the rule to determine the search 
apace, and the search component is the strategy whereby that 
space ig searched. This search space can be thought of as a 
tree with the goal statement as the root and descendant 
nodes determined by the selection component. The paths of 
this tree are then traversed according to a strategy given 
by the search component. 

Such a non-deterministic system, then, requires 
somewhat restrictive selection and search components because 


of the possibility of an infinite number of paths in the 
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search space or because of finite patha that do not lead to 
the empty clause (Ref. 161. 
3. PROLOG Example 

The selection component of PROLOG provides a rule 
that always selects the  leftmost literal (Ref. 3, 161% 
Therefore, the negative literals of a clause must be ordered 
and fixed, and only those search spaces (or developing 
trees) can be implemented (Ref. 16]. The search component 
in PROLOG provides a depth-firat strategy with the leftmost- 
descendant firat (derived by the above selection rule). The 
ordering of descendents is determined by the ordering of the 
definite clauses within the logic progran. 

Consider the following logic program (ignoring the 


atructure of the clauses and the unifying substitutions) 


(Ref. 12]: 

CEA SBS 
(23. BED AE 
(3) B=- E 

(4) C 

(5) D 

(6) F <-- G 

(7) F 

Given the goal statement <-- A, the search space for 


resolving this goal is depicted as a tree in Figure 2.1 
(Ref. 121% This search tree is an OR-tree whose nodes are 


possible goals that may occur during resolution of the goal 
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atatement. Each edge of the tree is labeled by the index to 
the particular clause of the logic program (above) that was 
used in the resolution process based upon the selection 
component previously deacribed. The search component 
progresses through the entire tree until either the empty 
clause ia found or the entire tree is searched [Ref. 12]. 
Although the unifying saubstitutiona are ignored here, those 
substitutions, made along a asauccessful path, yield an answer 


for the goal statement. 


i 
i <-- A 
l i l 
(1) |! i 
i i i 
l <-- B, C | 
| UN | 
l x 
(2) / \ (3) i 
l / \ 
| / \ 
<-- D, E, C <-- F, C i 
| i /N 
l ! Zo l 
| (5) | (6) / \ (7) 
l | / \ | 
l | / \ i 
l «-- E, C «-- G, C «-- C 
l i 
i i 
| 
l i 
l l 


Figure 2.1 Search Space Depicted as a Tree 


In order to avoid the redundancy of repeated 


aubgoals in the search tree, many PROLOG ayatema construct a 
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proof tree (Ref. 12]. A proof tree is generated for each 
node in the search tree. It ia an AND-tree where the root 
is the original goal and the leaves are the corresponding 
aubgoals of the search tree (Ref. 12]. The proof trees for 


nodes <-- D,E,C and <-- F,C are illustrated in figure 2.2 


"——-—U 
Pd 


Figure 2.2 Proof Trees 


During the resolution process, if a leaf cannot be 
unified or resolved with the head of another definite clause 
within the logic program, then a portion of the tree is 
erased. That portion is from the unresolvable leaf back to 


the most recent node that has not exhausted its potential 
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for matching (Ref. 12]. This process is called backtracking 
and the node at which backtracking stops is called a 
backtracking point. The search continues from the 
backtracking point pursuing the unsearched alternatives. A 
success requires that every path of the proof tree end with 
the empty clause (Ref. 121]. 

For example, in Figure 2.2(a), the leaf D can be 
resolved with the empty clause, but the leaf E cannot, 
sincethere are no clauses within the logic program that have 
a head to match it. Therefore the system must backtrack to 
node B since an alternative choice within the search tree 
(aee label (3), Figure 2.1)? is still available. That choice 
is depicted by the proof tree in Figure 2.2(b». 

This backtracking ia necessary because of the non- 
deterministic characteristics of the resolution of subgoals. 
Yet it is easy to see that fairly large and complex programs 


would require considerable backtracking. 


D. ADVANTAGES 

Logic programming offers seductive advantages when 
dealing with certain classes of problems. Ideas of logic 
have matured for centuries and have a concise and 
universally understood semantics. For bodies of knowledge 
that can be represented in a logical form, logic programming 
offers a means to prove things about that body of knowledge 


TRef. 20]. 
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1. Non-Procedural 
The notion of a non-procedural language is one in 
which the features of the language allow the programmer to 
concentrate more on "what" the program will do and not on 
"how" it will be done (Ref. S: p. 4991]. The goal-directed 
nature of logic programming embodies this notion, in that 
the programmer expresses the facta, in clause form, which 
assert the existence of the desired result [Ref. 5: p. S500]. 
The construction of the desired result, then, is based upon 
the resolution process of the logic programming language and 
removes the burden of "how" it will be done from the 
programmer. 
2. Simple Semantics 
Much of the power behind the semantics of 
programming rests with the notions of truth and inference 
(Ref. 18]. Assertions within the logic program are accepted 
as truth, and the clauses within the program are facts that 
allow inferences to be made based upon those assertions. 
3. Separation of Logic and Control 
Closely related to the non-procedural notion of 
programming is the notion of a logic component and a control 
component within the language (Ref. 8]. The control 
structures of conventional languages determine the order in 
which actions within the program take place. The fact that 
statements within that program must be executed in 4 


specified order to ensure correctness illustrates the 
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interrelationship of those control structures with the 
actual logic of the program (Ref. 5: p. 510]. 

Logic programming, on the other hand, allows a much 
greater separation of logic and control. Since the order of 
the clausea of a logic program has no effect upon the 
correctness of the program, the meaning of the program ia 
tied to the logical relationship of the program clauses, not 
the order in which they are executed (Ref. 2, 5, 81]. 

This separation of logic and control introduces the 
notion of separate analysis. Logical analysis is a concern 
for the correctness of the program, whereas, control 
analysis is a concern with the efficiency of the progran 
(Ref. 5, 81]. 

An obvious advantage of this separation, with regard 
to logic programming, is that the programmer can focus 
attention upon the details of the logic component when 
concerned with program correctness. Once a correct program 
has been established, the programmer can then focus upon the 
control component for efficiency considerations. This 
disjoint analysis simplifies the programmer’s task by 
removing the previously dependent relationships between the 


two components. 


E. DISADVANTAGES 
Although predicate logic offers some advantages to the 


programmer in terms of representation of certain kinds of 
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knowledge, it is important to consider whether predicate 
logic provides adequate support for reasoning about that 
knowledge (Ref. 18: p. 1391]. 

1. Undecidability and the Halting Problem 

A major drawback of predicate logic is the absence 
of a decision mechanism for dealing with the knowledge that 
can be inferred from stated assertions. Without such a 
mechanism, the resolution procedure blindly searches for a 
solution. 

Pure logic does not allow the expression of 
heuristics, which hinders the search for a path to a 
solution during the resolution process (Ref. 19: p. 231]. 
Therefore the resolution strategy may allow numerous 
unnecessary and divergent paths to be taken during the 
search. This can become a grossly inefficient method of 
search. 

Additionally, given a goal statement, using 
resolution to reason backward will produce a proof if the 
proposed goal statement is, in fact, a theorem based upon 
the assertions and clauses in the logic program. However, 
there is no guarantee that such a search will terminate if 
there is no proof [Ref. 19: p. 229]. Thia ia a version of 
the halting problem and is one that the AI community haa 
come to live with in their pursuit of proof methods, being 


content with a method that proves theorems even if it may 
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not halt on a non-theorer (Ref. 18: Dow 1391. Such 
procedures are said to be semidecidable. 
2. Combinatorial-Explosion 

All resolution strategies are subject to the problem 
of combinatorial-explosion, since the search trees generated 
can grow very unpredictably (Ref. 19: p. 229]. Somewhat 
akin to the halting problem, it means that a success for the 
proof of an actual theorem may be prevented due to the 
tremendous size and shape of the search space. 

3.  Axiomatize All Knowledge? 

The use of logic programming toward the solution of 
all problems leads to the restriction that all knowledge 
associated with the problem must be embodied in axioma 
(Ref. 19: Dl]: Such a process might require an 
enormous effort. 

a. Heuristics 

A considerable portion of this effort can be 
attributed to the fact that there is, ae mentioned above, no 
provision for heuristics in the knowledge representation. 
Therefore, such notions as best, next best, worst, etc. 
resist representation in logic and make a logical statement 
of the problem difficult or impossible. 

b. No Expression of State 

Another drawback of logic programming is the 
absence of a method for representing state transitions. 


Without such representation many problems embodied in finite 
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automata and systems programming become much more difficult 
to solve. 
4. Implementation Considerations 
The most notable implementation of logic programming 
is PROLOG, and the drawbacks noted here are factors that 
affect efficiency or sacrifice some of the power of the 
language in favor of more efficient execution. 
a. Backtracking and Efficiency 
As mentioned earlier, backtracking through a 
very large search space can be very costly to the search 
strategy, yet, for such resolution-type systems as PROLOG, 
it is very necessary. Unfortunately, it is this vast amount 
of time spent backtracking by the PROLOG interpreter that 
makes solutions to goal statements very slow in coming. 
b. Unification 
In order to regain some of this lost efficiency, 
many PROLOG implementations do not provide full unification. 
For instance, the resolution process would allow the 
unification of f(x,x) with £(y, g(y)), and would bind x to 
g(x) fRef. 71. The problem, of course, is that the attempt 
to prune the search tree allows circularity and the 
generation of infinite loops. 
C. Assertion/Retraction 
In the vein of predicate logic problem solving, 
there have been claims that PROLOG programs have no side 


effects (Ref. 7]. To some degree this is true, and that 
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degree rests with those portions of PROLOG which embody the 
features of predicate logic. For example, the use of 
assert’ and ’retract’ predicates in the language allows the 
assertion and retraction of axioma based upon conditions 
within the logic program. 

This violates the principle of predicate logic 
that each assertion ia an independent truth. Therefore, in 
the resolution process, there are different sets of axioms 
at different points in time (Ref. 3]. This dependence of 
some axioms and the addition or deletion of others diverges 
from the notion of separation of logic and control. In 
order to provide the programmer with a means to alter a 
database of facts, the advantages of separation of logic and 


control ‘(discussed above) are sacrificed. 


F. SUMMARY 

The logic programming paradigm offers the programmer a 
high level, non-procedural approach to problem solving 
enhanced by the simple semantics of Horn clauses. The 
resolution of goal statements and the unification of 
variables within that goal is at a level below that of the 
programmer. Additionally, the inherent capability to 
separate the logic of the problem solution from the factors 
which control the solution, allows the programmer to focus 
attention upon the logical relationships of the problem 


solution and program correctness. 
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Disadvantages seem to arise from the fact that all 
knowledge ia not declarative in nature and does not lend 
itself to axiomatized representation. Furthermore, certain 
control and efficiency issues are required to curb or 
contain the search of the knowledge base during the 
resolution process, and are amore naturally represented 


procedurally. 
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III. FUNCTIONAL PROGRAMMING 


A. BACKGROUND 

The foundation of functional programming lies in the 
notion of general recursive functions, which can express any 
computable function (Ref. 20: pp. 1-8]. McCarthy’s “pure” 
LISP first illustrated this concept by showing that a number 
of significant programs could be expressed as pure 
functions. These pure functions in LISP, of course, operate 
on list structures, but the notion may be generalized to 
other structures. 

The importance of the recursive function concept is the 
impact that it has on the nature of programming. In 
conventional languages imperative statements are used to 
alter control flow and update memory. These statements (as 
mentioned in chapter 2) are dependent upon the order in 
which they are executed. The recursive use of pure 
functions eliminates the requirement for these imperative 
statements and, as a result, is often called "assignment- 
less” or "variable-less” programming. This '"value-oriented" 
program-ming is based upon the use of pure expressions 
(discussed below) and offers the advantages of arithmetic 
and algebraic expressions to the programming language (Ref. 


20: p. 1-11. 
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Probably one of the most critical attacks upon the 
conventional programming languages of the von Neumann style 
came from Backus’ Turing Award Lecture, where he describes 
then as "fat and flabby” (Ref. 3: p. 6141]. His criticism of 
the framework, the  "word-at-a-time" programming, and the 
lack of useful mathematical properties of conventional 
programming languages (Ref. 3: p. 617] led to the design of 
his Functional Programming (FP) System. 

An important contribution in Backus’ FP paradigm ia 
the emphasis on the use of functionala (described below). 
The use of functionals allowa the programmer to raise 
himself above the recursive nature of the functio by 
providing a higher level of abstraction. At this higher 
level, the programs can be made more understandable and 


thereby much easier to maintain. 


B. EXPRESSIONS 


Expressions may be arithmetic, relational, or boolean, 


aa illustrated in Figure 3e la In conventional 
| | 
| arithmetic: (a + b) .». Cc | 
| | 
| relational: arb=0 | 
| | 
| boolean: -(a V b) | 
i | 


Figure 3.1 Types of Expressions 
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languages these types of expressions appear bn the right- 
hand side of an assignment statement. By eliminating the 
use of the assignment statement we can concern ourselves 
with "pure" expressions and the properties associated with 
them (Ref. 27; p. 28]. These properties are listed in 


Figure 3.2 and several are discussed below. 


* value is independent of the evaluation 
order 


* referential transparency 


* inputa to an operation are obvious in 
the written form 


* effects of an operation are obvious in 


i | 
| | 
| | 
i 
i | 
j | 
i x no side effects | 
i | 
| | 
i | 
i | 
| | 
| the written form | 
i | 


Figure 3.2 Propertiea of Pure Expressions 


a. Evaluation Order Independence 


An important property of pure expressions is the 
fact that within a given context, an expression has the same 
value regardless of the order in which it is evaluated. In 
fact, the evaluation of subexpressions within a given 
expression will not effect the evaluation of other 
subexpressions, and the order in which they are evaluated 


will not alter the final value of the overall expression. 
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This independence of evaluation order (also called 
the Church-Rosser property [Ref. 20: p. 1-3] is illustrated 
in Figure 3.3. Here a pure expression (with subexpressions) 
is shown in tree form, where the evaluation begins at the 


leaves of the tree. As soon as the leaves below an operator 
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Figure 3.3 Pure Expression as a Tree 


node have values, that operator can be applied to those 
values and that subexpression isa evaluated. Once evaluated, 
those subexpressions, as in this example, may become one of 
the arguments to another operator. Note that whether the 
"a t 


operator or the “-" operator is evaluated first does not 


alter the value of the entire expression. 
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The importance of context ens be illustrated by an 
"inpure" expression, as in figure 3.4, where assignments to 
variables can be made. If memory outside the context is 
allowed to be altered, then the expression is not “pure” and 


Side effects can result. In this case the value of the 


variable a can be altered by the evaluation of the 


function call. 


a + b ® Fc) 


where  F(ziinteger5: integer 


a := O; 
F= z»* Z 
end; 


Figure 3.4 Impure Expression 


2; Referential Transparency 


The property that the replacement of an expression 
(or subexpression) by its value is entirely independent of 
the surrounding expression in which it occurs is called 
referential transparency (Ref. 20: p. 1-3]. This property 
means that having evaluated an expression, it need not be 
evaluated again. This provides the universal ability to 
substitute equals for equals within a given context. 

For example, given the context b=3 and c=4 for the 


expression in Figure 3.5, referential transparency means 
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that having evaluated (b + c) to the number 7, the 
aubatitution of 7 for the other occurence of (b + c) vill 


not affect the value of the overall expression. 


Ca * (b * c)) * (d * Cb + @)) 


Figure 3.5 Pure Expression as a Tree 


C. FUNCTIONS 


Mathematical mappings from inputs to outputs are “pure” 


functions. Such pure functions are the "+", "s", and “-" 
operators of the pure expression in Figure 3.4. The results 
of these operations depends only upon the inputs. In fact, 


the notions of pure expressions and pure functions form an 
interesting dependency. In order for an expression to be 
pure (thus having the properties stated above) it must 
consist of pure functions. Additionally, if functions can 


be constructed with pure expressions (containing no 
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explicit or hidden assignment statements), then the 
function will retain the properties of pure expressions 
(Ref. 20: p. 1-5]. 
1. Function Application 

An applicative progran takes the form of an 
expression that consists of the application of pure 
EET iona to their arguments. Thus function application is 
the fundamental operation of applicative programming and is 
illustrated, in Figure 3.6, by the prefix function form of 


the expression in Figure 3.5. 


Figure 3.6  Prefix Forn 


Within the applicative programming language 
functions may be defined explicitly,  conditionally, 
recursively, or as the composition of other functions. The 
important point, however, is that these functions operate 
only on data (characters, numbers, etc.). 

2. Functionals 

In order to provide a higher level of abstraction, 
functionals are functions that take other functions as 
arguments. Functionals result from identifying recurring 


patterns in function definitions and abstracting them to a 
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higher level. The "map" functional is an excellent example, 
aince, it accepta functions such as "times", "plus", etc. 
and mapa them onto a list of ordered pairs. Such a 
functional eliminates the requirement to explicitly define 
"map times", “map_plus”, etc. functions. 

Functional programming, then, is a form of applica- 
tive programming that makes extensive use of functionals. 
Not only does it sinplify the programming process (fewer 
explicitly defined functions), but also offers additional 


propertiea which are listed in Figure 3.7 (Ref. 27: p. 30]. 


* easy to use existing functions to build 
new ones 


* easy to combine functions using composition 
* Subject to algebraic manipulation 

* easier to prove correct 

* easier to understand 


Figure 3.7 Properties of Functional Programs 


D. PROOF OF CORRECTNESS 

The mathematical properties of functional programming 
lend themselves to much more straightforward proof of 
correctness than either imperative languages or logic-based 
languages. Most often, the recursive function definitions 


of the functional program can be individually proved by 
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induction. Additionally, the functional programs themselves 
are subject to algebraic manipulation. A detailed analysis 
of auch algebraic properties is presented in Backus’ Turing 
Award Paper (Ref. 3]. 

A comparison of Hoare’s' axiomatic model of correctness 
(Ref. 28] with that of Mill’s functional model of 
correctness (Ref. 29] helps to illustrate this more 
straightforward proof of correctness method. 

1. Hoare’s Axiomatic Model 

Hoare’s axiomatic model of correctness uses the 
notation 

(P) S (Q) 

to state the required connection between the input assertion 
P, output assertion QA, and the program Cor part of a 
program) S. Partial correctness of program S results if and 
only if for every substitution of values which makes P true, 
then after execution of S, @ must be true. Total correct- 
ness results if it is proven that if P is true then S 
terminates (Ref. 21]. Hoare’s rules of inference, very 
Similar to the rules of predicate logic, are used to prove 
correctness of particular programs. By assuming the pre- 
and postassertions of every program statement, as well as 
the program itself, the rules of inference are used on each 
piece of the hierarchy to establish the proof. The problems 
arise fronm the fact that most statements of a program do not 


annotate their pre- and postconditions and that the proof of 
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iterative portions of the program requires recognition ad a 
"loop invariant" that is often difficult to ascertain. 
(Ref. 211]. 
2.  Mill^s Functional Model 

Mill^s functional model of correctness states the 
intended function of a program as a functional abstraction 
which summarizes the outcomes of the program (or part under 
consideration). This functional abstraction is independent 
of the control structures and data operations and reduces 
the question of correctness to one of function conpos 
and function equivalence (Ref. 21]. Partial correctness of 
program S means that “with respect to function F, every 
argument X, for which F is defined and FC(X)=Y, then if 
program S is executed with initial input vector X, its final 
output vector is Y." Total correctness is proven by showing 
that if X is in the domain of F then S terminates (Ref. 21]. 
The problem of determination of the loop invariant is 
minimized since the intended function of the loop may be 
easily converted to a loop invariant.The problem still 
remains that in most conventional programming languages most 


statements of the program do not annotate their function. 


E. ADVANTAGES 


ee Higher Level of Abstraction 


The advantages to be gained by functional program- 


ming are somewhat analagous to the advantages of structured 
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programming. The higher level of abstraction afforded by 
"goto-less" programming makes it easier to reason about and 
understand programs. The gotos exist at a lower level of 
abatraction and the programmer ia not burdened with those 
details. Similarly, the “assignment-less" property of 
functional programming encourages an even higher level of 
abstraction, providing a more systematic derivation of 
programa and resulting in greater underatandability 
(Ref. 20: p. 3-4]. Assignments, of course, exist but are 
hidden from the higher level of abatraction. 

Additionally, the functionals within the language 
provide a mechanism for achieving an even higher level of 
abatraction. Common patterns among user-defined functions 
can be abstracted out, named, .and thereafter referred to 
without concern for the underlying function composition. 

2. No Side Effects 

Many of the side effects associated with imperative 
programs result from the assignment statement and ita use in 
altering variables (local and non-local). This results in 
hidden interfaces within the program, which degrade both 
program correctness and understandability. In functional 
programming the assignment statement is eliminated and the 
interfaces manifest themselves in the expressions of the 
program. This means that the input-output connections of 


the subexpressions within an expression are visually obvious 
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(Ref. 20: p. 1-4] and confer no hidden interfaces or side 
effecta. 
3. Verification and Proof Techniques 

The functional model has several advantages over the 
axiomatic approach. By stating specifications and aub- 
apecifications as functions from an input space to an output 
apace, the functional model is a mathematical model in the 
strictest sense. The axlomatic approach organizes such 
apecificationa into Boolean functions represented by 
assertions on program variables, assertions given in terma 
of the relationship of the variables involved. The 
functional approach is in terma of the relationship of the 
two value sets involved. This means that the axiomatic 
approach maps from the current values of the variables into 
the two-tuple (True, False] instead of the more mathematical 
functional model which mapa fron the input value space to 
the output value space. Another advantage is that changes 
in a program that do not affect another program segment do 
not require a new proof of correctness for that segment. 
Thia results from the fact that the proof of a functional 
specification is in terms of the behavior of the program 
statement independent of the history of variables in the 
aegment. The assertions of the axiomatic approach, however, 
are restricted by variable history and interdependence with 
other variables (Ref. 21]. Additionally, different 


implementations of a particular apecification can be 
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substituted without requiring new proofs of other progran 
segments. 

Functional programming and the functional model 
described go hand-in-hand toward meeting the goals of 
atructured programming. The decomposition of the larger 
programming structure into simpler structures (stepwise 


refinement?) is easily afforded with functional programming 


in which larger programa or functions are merely 
compoaitions of simpler functions. The problem mentioned 
above regarding conventional languages and how each 


statement rarely annotates its function is eliminated with 
functional programming. Therefore, the functional program 
lenda itself to proof of correctness with the discussed 
model in a convenient manner. 
4. Parallelism 

The ability to perform parallel execution in 
functional programming is a direct result of the property of 
evaluation order independence inherited from pure 
expressions. The various nonoverlapping subexpressions 
within an expression can be evaluated simultaneously since 
the evaluation of one ia not dependent upon the evaluation 
of another. Therefore, a multiprocessor could assign 
various processors to evaluate different parts of an 
expression in parallel. 

Unlike conventional languages which require the 


programmer to identify the portions of a program which can 
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be run concurrently, " functional language can handle as 
many processors as there are subexpressions to evaluate, and 
the order in which the processors are assigned, or 
subexpressions are evaluated will not alter the final 
evaluation (it may, of course, affect the efficiency of 


execution). 


F. DISADVANTAGES 
1. Limited Problem Domain 
Although the mathematical properties of functional 
programming offer advantages, certain tradeoffs do result 
from those properties. These tradeoffs have a limiting 
effect upon the problem domain to which functional 
programming solutions are practical, or even feasible. 
Functional programming provides no notion of state 
nor does it provide any notion of time. This weakness in 
maintaining temporal relations restricts the use of 
functional programming for such state-oriented applications 
as operating systems, database management, or discrete 
simulation. 
2. Recursion and Inefficiency 
The recursive function definition is an important 
component within a functional programming language and is 
probably the most expensive. The expense of numerous 
recursive calls can be minimized if the hardware support can 


take advantage of the parallelism afforded by the language. 
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Unfortunately, such multiprocessor support for functional 
languages is not widespread and the use of such a language 
as “pure” LISP on a uniprocessor can be very alow depending 
upon the nested levels of recursion. Without the support 
for parallel execution, efficiency can quickly become a 
major factor in the effectiveness of the programming 
language. 
3. Industry Resistance to Change 

As with most new concepts, the resistance to change 
surfaces whenever the status quo is threatened. Most of 
industry is still tied to the von Neumann architecture and 
"mind set" (both financially and intellectually). Until the 
decisionmakers within the industrial complex are convinced 
that the advantages afforded by new concepts will outweigh 
the expenditure in time, personnel training, and money, 
these new concepts will remain at the theoretical or 


experimental level. 


G. SUMMARY 

The functional programming paradigm provides the 
programmer with avery high level of abstraction, making it 
easier to reason about and understand programs. In contrast 
to von Neumann languages, functional languages are free from 
Side effects resulting from heavy dependance upon the 
assignment statement. Additionally, the non-sequential 


nature of functional programming, based upon the property of 
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evaluation order independence, lends itself to parallel 
execution in a multi-processor environment. 

The disadvantages of the functional programming paradigm 
rest with its somewhat limited problem domain, because of 
its weaknesa in representing temporal relationships. 
Although functional languages lend themselves to parallel 
execution, without more effective use, in terms of hardware 
support, of the parallel nature of the language, the cost of 


numerous recursive calls is inefficiency. 
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IV. FEASIBILITY OF AN INTEGRATED LANGUAGE 


A.  PROCEDURAL AND DECLARATIVE COMPONENTS 

Having described both the logic programming and 
functional programming paradigma, we now consider the 
feasibility of a language which integrates some of the 
features of both programming paradigma. It should be noted 
here that both logic programming and functional programming 
E. within a classification of programming which MacLennan 
refera to as  "value-oriented" programming (Ref. 22]. He 
includes equational programming (Ref. 23] and relational 
programming as well (Ref. 24], but here we consider 
equational programming a more reatrictive form of functional 
programming and relational programming a form of functional 
programming (since a function is a relation) which can deal 
with multi-valued functions. The focus, then, is on the 
feasibility of integrating a procedural component 
(functional programming) and a declarative component (logic 
programming) within a single language. 

The non-procedural aspects of logic programming make it 
very advantageous for stating facts (or axioms) from which 


knowledge can be inferred, or about which queries can be 


made. Yet ig is unnatural to define everything 
declaratively. For example, most PROLOG implementations 
define numbers and the operations on them procedurally. In 
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such instances it is not only unnatural to define then 
declaratively, it ia lesa efficient (Ref. 25]. 

By contrast, the  non-declarative aspect of functional 
programming can make the manipulation of information in a 
knowledge base very tedious and inconvenient. Since the 
search of such a knowledge base is explicit, the programmer 
must define functions that perform the search or comparisons 
required. These contrasting aspects of both programming 
paradigms will be illustrated and explained in the following 


examples. 


B. EXAMPLES OF CONTRAST 
1. Declarative Versus Procedural 
Consider the PROLOG program in Figure 4.1 and the 

LISP program in Figure 4.2. The program in figure 4.1 can 
be used to find out such information as the annual salary, 
weekly tax, etc. of an employee asserted in the database. 
By merely satisfying the goal 

<-- weekly tax(John Doe, X) 
the aystem will perform the necessary resolution, 
backtracking and unification to produce the weekly tax of 
John Doe. Similarly, the LISP program in Figure 4.2 will 
return that individuals weekly tax when the function 

weekly tax(John Doe?) 
is called. In comparison, note that although the three 


clauses for weekly_tax in the logic program can be defined 
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by one function (with a 


program, 


conditional) in 


both programs perform 


the functional 


the same function and their 


difference is primarily syntactical. 


weekly_salary(John_Doe,5300). 


weekly salary(Jim Jones,350). 


annual salary(X,Y) «4«-- weekly salary(X,2), 


weekly tax(X,Y) «-- 


Y is (Z * 48). 


weekly tax(X,Y) «-- annual salary(X,2)5, Z »- 20000, 
weekly salary(X,B), 
Y is (B * .06). 

weekly _tax(X,Y) «-- annual salary(X,25, Z »- 10000, 


Z « 20000, weekly salary(X,B), 


Y is (B * .O4)5. 
annual salary(X,Z), Z < 10000, 


weekly salary(X,B), 


Y is (B * 


.02). 
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Figure 4.1 PROLOG Progran 


However, 


€«-- weekly tax(X,Y), 


which will return all pairs 


weekly tax, ia 


of 


not possible 
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a query to the logic program such as 


weekly tax(Z,Y) , 
employees that pay the same 


in the functional program 


without defining a nested function that explicitly checks 
the database against a conditional expression and constructa 


a new list with the results. 


(SETQ weekly salary(cons John Doe SOO) 
(cons ^Jim Jones 350 ...)) 
DEFUN(( 
(weekly tax(Name) 
(PROG (WS) 
(SETQ WS (‘cdr (sassoc Name weekly_salary))) 
(COND 
(( GEQ 20000 (TIMES 48 WS )3) 
(TIMES .06 WS > 
(( GEQ 10000 (TIMES 48 WS )3) 
(TIMES .04 WS > 


CT, (TIMES  .02 WS )) 3) )) 


Figure 4.2 LISP Progran 


2. PROLOG Use of Cut 
This illustrates that the pattern matching in 
PROLOG, resulting from the resolution of subgoals, ia an 
advantage during the search of the database, because the 
method of search is at a lower level than that of the 


program. However, the same PROLOG implementation of logic 
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programming that offers this abstraction also requires the 


use of the “cut” symbol. The cut symbol is a means of 
halting unnecessary or unwanted backtracking. Its use 
within the clauses of a logic program requires the 


programmer to be intimately familiar with the method of 
backtracking, or side effects may be introduced into the 
program. This is because the cut symbol alters the way 
backtracking works after its use. The effect of the cut is 
to remove the place markers for certain goals so that they 
cannot be resatisfied, and commits the system to every 
unification made since that clause was entered (Ref. 2: pp. 
64-68]. 

The side effects of using the cut symbol arise from 
the fact that a clause may be used in a manner for which it 
was not intended. For instance, consider the two clauses: 

append<({],X,X) <-- "cut". 
‘append((A!BJ],C,CA!ID]) <-- append(B,C,D). 
where the cut prevents unnecessary backtracking. When 
resolving goals like 
«-- append(íta,b,cl1,íd,e1,XD 
or 
«-- append(íta,b,c21,X,Y») 
the cut works as intended and is appropriate from an 
efficiency standpoint. However, if the goal 
<-- appendí(X,Y,la,b,cl) 


is resolved, it would be matched and unified with the first 
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clause yielding X = [] and Y = [a,b,c]. The cut would 
prevent any further resolution and no other answers could be 
generated even though others existed (Ref. 2: pp. 65-66]. 
Aa the cut is placed deeper in the body of a clause, to 
freeze unification made to that point, the side effects 
become more difficult for the programmer to predict. 

In an attempt to provide a means of controlling the 
cost of backtracking, the PROLOG implementation of logic 
programming requires the programmer to be aware of the 
underlying backtracking mechanism, introduces possible side 
effects, and negates the advantage gained by keeping the 
resolution mechanism at a lower level than that of the 


programmer. 


C. INTEGRATION 

The previous examples help to illustrate certain 
problems and inadequacies that result from either a strictly 
procedural approach to programming, or from a declarative 
approach interspersed with procedural features for efficient 
control. The PROLOG implementation of logic programming is 
a somewhat integrated approach, though to a very small 
degree, and the major problems with that approach have been 
described. The existence, and utility, of PROLOG gives some 
credence, then, to the feasibility of an integrated 
language. However, the problems with PROLOG seem to stem 


from the features of the language which are somewhat foreign 
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to Kowalski’s concepts (described in chapter 2) of separa- 
tion of logic and control, and LUSH resolution of Horn 
clauses. 

In keeping with these concepts, a procedural component, 
namely functional programming, can provide the control 
characteristica for an effective and efficient declarative 
component, as well as provide a means for representing  non- 
declarative knowledge. 

1. Procedural Call From Declarative Component 

To illustrate this notion, consider first the 
ability to call the procedural component from the 
declarative component. For example, the logic program in 


Figure 4.1 used three clauses to define weekly_tax. The 


weekly_tax(X,Y) <-- weekly salary(X,B), 
annual salary(X,2), 
Y is * (COND 
( (GEQ 20000 Z) 
(TIMES .06 B) 
( (GEQ 10000 Z) 
(TIMES .04 B) 


(T «(TIMES .02 B?) )) )) 


Figure 4.3 Call to Procedural Component 
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advantages gained by backtracking within a single clause 
become cumbersome, tedious, and expensive when backtracking 
must occur through several clauses that have the same head. 
In an integrated approach, the ability to define weekly tax 
(Figure 4.3) with a procedural call (denoted by the "*"” 
symbol), which performs the conditional control, allows the 
inatantiated values of the variables Z and B, unified 
through resolution, to be used in the function to 
instantiate the variable Y. The requirement for three 
clauses with the same head has been reduced to one clause 
where resolution is no longer needlessly replicated. 

In such an example, note that the functional call 
from the declarative component merely returns the value of 
the evaluated function. Such a function can be evaluated by 
theprocedural interpreter and is regarded as a standard 


functional expression. 


24 Declarative Call From Procedural Component 


A call to the declarative component from the 
procedural Component, on the other hand, requires a 
rethinking of the resolution process. For example, Figure 


4.4 illustrates such a call in an attempt to use the 
advantages of resolution, instead of explicitly defining a 
function, to search the knowledge base and perform the 
unifications which provide a solution. But in this case the 
call to the declarative component cannot merely return the 


result of an evaluated expression. In this simple example, 


30 


(defun append ¢ L M D 
(cond 


(( null L2 M D 


i | 
| | 
i | 
| ' 
i 
| | 
| i 
| (T (cons (car L) (append ‘(cdr L) M 50 )) ) | 
‘ 
| | 
| i 
| append ( #(weekly_Tax(X,30), weekly_tax(Y,30)), i 
| ] 
| ^*(John, Smith) ) 
| | 
| | 


Figure 4.4 Call to Declarative Component 


the procedural component expects the declarative call to 
return a list of employees which pay 30 dollars in weekly 
tax. However, suppose the uninstantiated variable Z was in 
place of the 30. The resulting list of employees would be 
dependent upon the various instantiations of Z, and without 
knowing which employees were associated with those values of 
Z, the resulting list would be meaningless. What about a 3- 
tuple list which yields the X, Y, and Z instantiations of 
every solution? Such a list could become a rather large 
list of permutations with, possibly, redundant information. 
Here the results to be returned are more complicated and 
require modification to the resolution mechanism within the 
declarative interpreter. 

Such modification, discussed in the following chapter, 


is based upon two important observations that arise from 


Əl 


the previous example: 


- Queries (calla to the declarative component) must be 
qualified. Qualifications auch as ’all’, ’any’, etc. 
must be made explicitly in the query. 


- Unification must be based upon the given context (or 
environment) in which the declarative call is made. A 
context isa a list of unificationa (or bindings) which 
provide a constraint upon the resolution of the 
declarative clause. 

These observations form the foundation upon which the 


features of a truly integrated language can be described. 
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V. FEATURES OF_AN INTEGRATED LANGUAGE 


A. SYNTAX ISSUES DEFERRED 

Whether the syntax of an integrated language should be 
uniform (either functionally based or logically based), or 
whether it ahould be mixed, is an issue that will be 
deferred at thia point. The intention is to deseribe the 
important features of an integrated language and discuss the 
modifications required of the resolution process within the 
declarative component. In keeping with the examples of the 
previous chapter, the use of PROLOG and LISP syntax can 
adequately represent the points to be made, and the mixed 
syntax will better illustrate the transfer of control from 
procedural interpretation to declarative, and vice versa. 

With this transfer in mind, the “#" symbol will 
represent the transfer of control from one component to the 
other. The results from a procedural call (function 
application) within the declarative component must be the 
value of the evaluated function, and will be used to 
instantiate (or unify) a variable within the clause. The 
results from a declarative call (resolution process) within 
the procedural component, on the other hand, must return a 
list of solutions to the query. Each solution is itself a 
list of variable bindings that provide a solution to the 


given query. 
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B. QUALIFICATION OF A QUERY 
As described in the previous chapter, a call to the 
declarative component aust be qualified to ensure that 
expected, and meaningful, results are returned to the 
procedural component. In general, the programmer may 
require several different types of resulta from the 
declarative component. In some instances the programmer may 
require a list of all possible solutions to a given query. 
But in other instances, the programmer might require only a 
limited number (or even one) of all the possible solutions. 
Based upon the functions described in Robinson's LOGLISP 
(Ref. 26) these qualifiers can be represented by the 
following: 
ALL - returns, as a result of the declarative call, a 
list of all tuples which satisfy the query within 
the constraints of the current context (details of 


resolution within a context are in a later section). 


ANY K - returns a list with no more than K of the tuples 
returned by ALL. 


With these two qualifiers as the foundation, the 
programmer may use the functional component of the language 
to define, for convenience, functions which perform special, 
or redundant, cases of the basic qualifiers. For example, 
the qualification ANY 1 to the given goal statement, will 
return a list containing the single list of variable 


bindings that provides one solution. A function THE, which 
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will return those bindings in a single list, and may be 
defined by 


THE (Q) = #ANY 1 (0). 


C. QUERIES AND THEIR CONTEXT 
Associated with each query, or goal statement to be 
resolved, is an implicit context within which certain 
constraints are placed upon the resolution process. These 
constraints are variables which are already bound to values. 
If variables that are part of the goal statement are already 
bound, then those variables cannot be re-instantiated during 
the resolution process. For those variables that are not 
defined in the current context of the query, they are 
considered free variables and can be instantiated (or bound) 
during the resolution proceas. 
1. Context Description 
The context associated with each query contains all 
bound variables, of local scope, which may be bound to terms 
or to other variables. The fact that variables may be bound 
to other variables makes the unification somewhat more 
complicated, but is necessary to allow the resolution of the 
goal to progress as intended. It should be noted, however, 
that such indirect binding must eventually terminate with a 
binding to a term within that context. 
The bindings within a given context can be denoted 


in a manner that lends itself to LUSH resolution (see 


9 


Chapter 2), which will simplify the checking of variables 


within that context. For example, 


X <-- Y 
Y <-- a 
2 <-- b 


represents the context (variables in uppercase, terma in 
lowercase) of a given query Q, within which X ia bound to Y, 
YS in turn, ia bound to "a", and Z is bound to "b". 
Therefore, a query such as 
P(T,X,V) 
would have two free variables, T and V, and the variable X 
would be bound to the term "a” during each resolution 
process in the search for a solution. 
2. Context Algorithm 

For a given query @Q and its associated context C, 
the constraints placed upon the resolution of Q are 
represented by the variables that are already bound. The 
following algorithm is concerned with a query of the form 


Q(CP, ,P 


q^ 2 e 6e a »P >? 


where 
represents each predicate, and C is the context of the 


query. 
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Algorithm: 
repeat 
for (each variable = of every predicate Pi, in QD 
resolve EEUU {perform LUSH resolution on } 


{database C } 


[s 


COX 5 = nil 


J 
then X. is a free variable and do nothing 


else instantiate = to term tie returned from 





resolution of a within the query Q 
place the binding tuple in the list So that 
will contain all such bindings 
until (all variables are checked). 
Once these constraints have been placed upon Q, the 


query can then be resolved (subject to the modifications 


described below). 


D. MODIFICATION TO THE RESOLUTION PROCESS 

Most PROLOG implementations provide for the resolution 
of goal statements based upon the LUSH resolution described 
in Chapter 2. When a programmer makes a query to the 
knowledge base and a solution is provided, the programmer 
may then induce a failure (usually by hitting return) which 
invokes backtracking in search of another distinct solution. 
For our integration purposes, the qualifiers ALL and ANY K 
determines at the outset whether one, more, or all solutions 


are required. 
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From the above context algorithm, the constraints placed 
upon the query Q are defined in the list of bindings So: 
This list contains the instantiated variables of @ cif any), 
and have been so instantiated in @. The query Q may now be 
resolved by the declarative component, the PROLOG 
interpreter for this example, until a solution isa found or a 
failure is obtained. Given a solution is found, let the 
associated list of all solutions be denoted by 


S = (31,38 P 


k?’ 


E v e a era? 


where 31 is the first solution obtained in the resolution 
process. 

In constructing such a solution, the following algorithm 
represents the modification to the resolution mechanism of 
the declarative interpreter that will allow its 
construction. The algorithm modifies the basic declarative 
interpreter such that the entire results of the qualified 
query are returned as a list of bindings which satisfy that 
query. Once the declarative resolution mechanism returns a 
failure, there are no more solutions to be obtained, and the 
search is halted. If it is the first attempt at a solution, 
then the empty list is returned, otherwise the list of 
solutions to that point are returned. 

Algorithm: 


Given the qualifier to the query, the query Q, and the 


constraint bindings in C, 
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First i, 
repeat 
resolve Q 
if FAIL {from resolution of Q} 


then if i = 1 








HALT; 
else (have a solution) 
place binding tuples of solution in a list 
(returned from resolution of Q) 
append this list to So 
(to include initialization bindings) 
let Si denote new list 
place Si in S 
induce FAILURE (standard PROLOG mechanism to ) 


{search for another solution } 


if qualifier = ANY K {check qualifier} 





Next i 
until HALT 
return S. 
Notice that the binding constraints placed upon the 
initial query must be explicitly included with the solution 


bindings resulting from the resolution of Q. These bindings 
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were saved in So when the constraint instantiations were 
made in Q. They must be returned as part of solutions in S 
since they provide variable bindings that are part of the 
aolution. 

Although there is no explicit check for the ALL 
qualifier in the algorithm, it ia felt that its syntactic 
inclusion, aa part of the qualification to the query, will 


provide more regularity and structure to the integration 


interface. 


E. AN INTEGRATION EXAMPLE 

To illustrate the extensibility offered the programmer 
from the functional component, consider the function in 
Figure 5.1. This function takes the list of solutions 


obtained from the declarative call, represented by 


where 
Sy = COX, ti? (X, t2) eee (Xo t?» 

and allows the programmer to specify which variables within 
the declarative call will be returned as meaningful results. 
This general function provides the programmer considerable 
flexibility in utilizing or manipulating the results 
obtained from the declarative call. 

For example, consider a knowledge base of facts 


concerning the armed forces of various countries, their 


mobilization status, geographical relationships, etc. 
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Return list =  ((NLAMBDA L) 
(PROG ( S VARLIST RESULTS ) 
(SETQ S (EVAL (LAST L>>) 


(SETQ VARLIST C(LDIFFERENCE L 


(SETQ RESULTS 
(MAPCAR S LAMBDA (3,1) 
(MAPCAR VARLIST LAMBDA (X) 


(ASSOC X S, )) )) )) 


| 
| 
| 
| 
| 
i 
| 
i 
| 
| 
(LAST L))) | 
| 
i 
| 
i 
| 
i 
i 
| 
i | 
| 


Figure 5.1 Function Definition 


Then a question of the forn 
"Which Warsaw Pact countries have exercised armored 
divisions within the past six months, and what divisions 
were they?" 

could be handled by the following function (which makes a 

call to the declarative component): 

Return list (X Y C#ALL (Ccountry(X), warsaw_pact(X), 
armored division(x,Y), 
mnobilize(Y,D), D > Z »)) 

Here we assume that the variable Z, representing a Julian 
date, has been bound outside the function call (perhaps 


based upon a previous query regarding information within the 
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last six months). Therefore, the variable Z is in the 
current context GC, is instantiated in the query, and 


saved in 5 based upon the context algorithm described 


o" 
above. 

Turning to the function in Figure 3.1, the solutions 
returned in S (based upon the modified resolution algorithm 
above) are, in effect, associated with the variables 
explicitly listed as an argument to Return list, and only 
these values are returned. In this case the variables X and 
Y are listed, and may be exemplified by results such as 

((Poland Fifth armored) (Poland Seventh armored) 
(Hungary Second armored) (DDR Second armored)). 

Other queries can be made to the declarative component 
based upon the solutions provided by the previous results. 
For instance, a follow-on question like 

“Where is the Second armored division of the DDR 

currently located?” 
could be resolved by first instantiating var S RTL and Y 
outside the query (possibly using SETQ) and using the 
function Return_list again with a different call to the 
declarative component. Therefore, the function call 

Return liat (W (RANY 1 (armored _division(X,Y), 
current location(Y,W5)5) ) 
would return the current location (given such information is 


in the knowledge base) of the instantiated armored division. 
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F. SUMMARY 

The previous examples illustrate the notion of a 
procedural component providing the control for logical 
relationships in the declarative component of an integrated 
language. They demonstrate the concept of resolution within 
a context, described above, and illustrate the flexibility 
provided the programmer, in that user defined functions can 
be created to best utilize or manipulate the results 
provided by a query to the declarative component. 

By strict enforcement of the separation of logic and 
control, the use of the "cut" symbol can be eliminated. Its 
use in PROLOG is based upon the fact that the programmer ia 
required to provide control mechanisms within the logical 
relationships that are created. A logical renard his that 
is so complex that a cut is used by the programmer (to 
effectively save information to that point by halting the 
backtracking mechanism) must be simplified in a way that 
makes each logical relationship a separate entity. 
Therefore, the programmer still has the burden of 
understanding the manner and method with which logical 
relationships are defined in the declarative component, but, 
more importantly, the requirement to understand the low- 


level details of backtracking is removed. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

The previous chapter described the initial features to 
be considered in the integration of logic programming and 
functional programming. Preaented haa been an argument that 
an integrated language better supports Kowalski’s notion of 
Aeparation o£ logic and control (Rat. 81. This argument haa 
been based upon the idea that declarative sorta o£ knowledge 
(facts and logical relationships) should be expressed in a 
declarative way, and that procedural sorts of knowledge 
(manipulation, control, and utilization of data) should be 
expressed in a procedural way. 

Toward this end, the declarative component of an 
integrated language establishes a knowledge base of facts 
(or assertions) as well as rules for associating those 
facts, determining logical relationships among thea Or even 
inferring new knowledge and relationships. The procedural 
component, then, is the interactive tool for explicitly 
controlling those logical relationships and the knowledge 
base of facts upon which they are built. 

The explicit control afforded by the procedural 
component has eliminated redundant and unnecessary 
backtracking. Since multiple rules are no longer required 


to define a single logical relationship, redundant 
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backtracking through the bodies of several clauses with the 
sane head ids avoided. This allows the programmer to 
associate one clause with one logical relationship, 
providing clearer understanding and easier modification and 
maintenance. 

The necessary control for utilizing and manipulating 
results obtained from a query to the declarative knowledge 
base is provided by the programmer. This control, however, 
is no longer at the low level required when using the “cut" 
symbol. The control is now concerned with logical 
relationships and avoids the side effects resulting from the 
use of the “cut”. 

Additionally, the programmer is no longer concerned with 
explicitly defining the search of a knowledge base of 
assertions and rules. By using the procedural component to 
manipulate the results obtained from a query to the 
declarative component, the programmer can focus on higher- 
level issues of interrelationships among the results of such 
a query, not on the lower-level details of how that search 
was performed. 

All of these conclusions support the ideas of 
abstraction, higher-level focus, and information hiding, 
discussed in Chapters 1 through 4. The argument for an 
integrated language, based upon the features described in 
Chapter 5, is conceptually sound, and has further supported 


the idea that representing varied forms of 


65 


knowledge in a strictly procedural, or strictly declarative, 
manner forces the programmer to contort the representation 
of one form of knowledge to fit its expression in another 


forn. 


B. RECOMMENDATIONS 

Having provided a conceptual framework for the design of 
an integrated language, future emphasis should be placed 
upon more detailed design, and eventual implementation, of 
each of the procedural and declarative components of the 
language. A decision must be made regarding the choice of 
syntax (uniform or mixed) of the language, and the detailed 
features of each component aust be based upon that decision. 
For instance, the choice of a functionally-based uniform 
syntax would require a redesign of the manner in which 
logical assertions and relationships are represented and 
interpreted. Such a redesign, however, may greatly simplify 
the integration interface described in the previous craca 

Additionally, emphasis must be placed upon issues which 
were of concern regarding each programming paradigm in and 
of itself. Such issues are efficiency considerations and 
parallelism. With regard to efficiency, both the functional 
programming language and the logic programming languages are 
inherently slow without adequate hardware support. This 


slowness ias a result of recursion in the functional language 
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and searching in the logic language. Having an integrated 
language with both features emphasizes the necessity for the 
hardware support for parallel execution. 

Fortunately, both functional programming and logic 
programming support the notion of parallel execution, and 
with adequate hardware support, an integrated language could 
provide the best features of a functionally-based procedural 
component, as well as the best features of a logically-based 
declarative component, and that is sufficiently efficient to 


provide timely calculations and results. 
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